1. Field of the Invention
The present invention generally relates to methods and systems for providing documents structured as hierarchies of information. In particular, the present invention relates to methods and systems to avoid collisions between index role children and named role children in such structured documents.
2. Description of the Related Art
Extensible Markup Language (XML) is a standard for creating languages that meet the XML criteria. It is extensible, because data represented according to the XML standard may be marked up in any manner desired. For example, unlike Hyper Text Markup Language (HTML), the developer is free to add previously undefined tags to an XML document and an XML parser will be able to read the document. An XML document is a structured file. More particularly, XML documents are structured as hierarchies of information. That is, the elements (which must adhere to a limited set of rules) of an XML document may be thought as being organized in parent-child and sibling relationships (children that are at a same hierarchical level). FIG. 1 shows an example of such parent-child relationships. As shown, the hierarchy includes a root node 102 identified by the <doc> tag. The root node 102 has two children, namely Parent 1 112 and Parent 2 104. In turn, Parent 1 112 has two children: child 11 and child 12. Similarly, Parent 2 104 has a child 21 identified by the tag <child 21> and a text child “text2” 110. Continuing, <child 21> contains the text “text 1”, as shown at 108. Such a hierarchical nodal relationship lends itself well to user interfaces (UI), for example, in which the nested relationship of the displayed windows, menus and the like are readily represented in such a hierarchical format.
The relationship of a child node with its parent may be characterized by means of a named role. Named children are associated with a specific role such as, for example, the placement of an element of a document on a Web page. Children may also be organized as indexed children, Indexed children have an inherent order, and the order of the indexed elements defines this inherent order.
FIG. 2 shows an example of a structured file illustrating an indexed relationship of the children of a parent node. The root node parent is bounded by a start tag <parent> 202 and an end tag </parent> 212. The parent node 202 may be said to contain the child nodes A, B, C and D, as shown at 204, 206, 208 and 210, respectively. A, B, C and D may be characterized as index children, and the order in which the children are listed defines the order of the index: first node A, then node B, followed by node C and lastly node D.
FIG. 3 shows another example of a structured file or document, illustrating named role children. The document of FIG. 3 includes a root node having a start tag <Parent> as shown at 302 and an end tag </Parent> referenced at 320. The Parent node 302 includes four named role children; namely Top 304, Bottom 308, Left 312 and Right 316. The named role children Top, Bottom, Left and Right 304, 308, 312 qualify the parent-child relationship; that is, they specify how the children are used by the parent. The roles may be specified within a Schema; that is, a model document that defines the structure of, for example, an XML document. XML Schemas, for example, are defined at www.w3.org.
In this case, the named role children Top, Bottom, Left and Right specify the placement of their respective children components A, B, C and D within the parent 302 and have no presence on the user interface but merely serve as positional indicators. To achieve the same functionality (i.e., specifying the placement of the components A, B, C and D within the structured document) using only indexed children requires respecting an arbitrary convention that specifies that, for example, the first indexed child A is to be rendered on top of the document, the second indexed child B is to be rendered on the bottom, the third indexed child C is to be rendered is to be rendered on the left and the fourth indexed child D is to be rendered on the right. This is because the order of the index children does not inherently imply their position or order on a user interface representation or within the structured hierarchical document. Such conventions are not flexible or practical. Moreover, it also not practical to insert a named role tag between each parent and each of its children. For instance, there are occasions where an indexed relationship (as shown in FIG. 2) is better suited to define the parent-child relationship and the relationship between children than is a named role relationship. For example, when the number of children becomes large, it becomes impractical to insert a role tag between each child and its parent. In other words, is unworkable to define a role for an arbitrary and unbounded indexed relationship. There are occasions, however, when a same parent requires (or would benefit from inclusion of) both indexed and named role children. For example, a Web page may include several predefined portions in which it is desired to put advertisements. Such predefined portions may readily be defined as named role children. The central portion of the page, however, may be reserved for content that changes from page to page. Indexed children may then be the most efficient manner of representing such content. Therefore, some manner of enabling both indexed and role children to co-exist under the same element is needed. However, merely placing indexed children directly under its parent (without a role tag between them) is not optimal, as collisions may occur between the tags of index children and that of the pre-defined named roles. Indeed, as the page is parsed and validated, each child may be examined to determine if its tag is listed as one of the predefined role tags. If the tag is listed, the child is a role child and if the tag is not listed, it is an indexed child. There could be instances, however, in which the tag for an intended index component is also listed among the predefined role tags. A collision of the names of the component and the roles occurs and the representation thereof in the UI is often unpredictable.
FIG. 4, which is a diagram of a conventional hierarchically structured document, illustrating just such a collision between a named role child and indexed components. As shown therein, the parent node is bounded by a start tag at 402 and an end tag at 424. The end tags of the children are not shown in FIG. 4, for clarity of illustration purposes only. The parent has a number of children, whose relationship therewith is specified by named roles 404, 412 and 416. Indeed, component A 406 may be rendered on top of the document, as the role child 404, in this illustrative example, specifies that the component A is to be rendered at a predetermined position at the top of the document. Likewise, the components C 414 and D 418 may be rendered to the left and right, respectively, of the document. These positional relationships are defined by the named roles, such as shown at 412 and 416. Components 408 and 410 are not preceded by a recognized named role and are, therefore, considered to be indexed children, and are to be rendered in the order in which they appear. Likewise, component 420 may be intended as the component child of a named role child, or may be intended as the first component of a set of index children 420, 422. However, there is an ambiguity here, as the tag of the child 420 is identical to that of a predefined named role, such as shown at 416. Therefore, a collision occurs and the document may not render as intended. The tag <Right2> 422, in this example, has no counterpart in the definition and list of the named roles and may be correctly interpreted as an index child.
What are needed, therefore, are methods and mechanisms to enable role children and index children to co-exist under a same parent without running the risk of collisions between the names assigned to index components and the names assigned to the predefined role children. What are also needed are methods and mechanisms to achieve this functionality in XML and/or other markup languages or standards.